System and method for processing single sale transactions involving one or more payors

ABSTRACT

A system for processing sales transaction may include a first computing device in communication with a buyer-operated computing device, and a computer-readable storage medium in communication with the first computing device. The computer-readable storage medium may include programming instructions for receiving an order including one or more of a commitment of a buyer to purchase an item, and a preferred share value associated with the buyer, receiving contact information associated with one or more third parties, receiving a fractional share value associated with each of the one or more third parties, and in response to a sum of the fractional share values associated with each third party and the preferred share value equaling the purchase price associated with the item, using the received contact information to send a message to each third party. Each message may include the fractional share associated with the third party.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S. patentapplication Ser. No. 13/113,739 filed on May 23, 2011, which is acontinuation of U.S. patent application Ser. No. 12/476,058 filed onJun. 1, 2009, which claims priority to Provisional Application No.61/057,272 filed May 30, 2008, the disclosures of which are incorporatedherein by reference in their entireties.

FIELD OF THE INVENTION

The present invention relates generally to a system and method forprocessing single sales transactions that may have one or more payors.More particularly, the present invention relates to acomputer-implemented system and method permitting a buyer to commit tothe purchase of one or more items in a single sale transaction, thusensuring eventual completion of the purchase transaction, whilenevertheless providing for recruitment of additional payors to join inthe purchase of the item(s) by contributing payments to be appliedtoward the purchase price, thus reducing the share of the purchase priceto be borne by the original buyer.

BACKGROUND

Various group purchasing methods are well known in the art. For example,a group may agree in advance to purchase a particular single item as agift for a family member, coworker, etc. and to divide the eventual costamong the members of the group. In many instances, a lead member of thegroup will make the purchase, pay for the item in full, and thensubsequently seek cash reimbursement of a portion of the cost from theother members of the group. Any failure of a group member to pay his orher portion of the cost is typically borne by the lead member of thegroup, since the purchase has already been completed, and paid for, bythe lead member.

By way of further example, in advance of any purchase, cashcontributions may be sought for application toward purchase of aspecific item. However, if the total amount of contributions is lessthan the purchase price of the item, the purchase cannot be completed.The realization that the purchase cannot be completed may occur at sucha time that it is then inconvenient or impossible to obtain a substituteitem in a timely fashion, e.g. for presentation as a retirement gift toa co-worker at a retirement party.

Further, any approach in which one or more buyers agree with a merchantto purchase an item from the merchant only on a conditional basis, e.g.provided that sufficient funds can be raised, is unsatisfactory to themerchant because of the high degree of uncertainty with respect toeventual completion of the sale transaction, which can complicate themerchant's inventory management, sales projections, etc.

SUMMARY

Before the present methods are described, it is to be understood thatthis invention is not limited to the particular systems, methodologiesor protocols described, as these may vary. It is also to be understoodthat the terminology used herein is for the purpose of describingparticular embodiments only, and is not intended to limit the scope ofthe present disclosure which will be limited only by the appendedclaims.

It must be noted that as used herein and in the appended claims, thesingular forms “a,” “an,” and “the” include plural reference unless thecontext clearly dictates otherwise. Unless defined otherwise, alltechnical and scientific terms used herein have the same meanings ascommonly understood by one of ordinary skill in the art. As used herein,the term “comprising” means “including, but not limited to.”

In an embodiment, a system for processing sales transactions may includea first computing device in communication with a buyer-operatedcomputing device, and a computer-readable storage medium incommunication with the first computing device. The computer-readablestorage medium may include one or more programming instructions forreceiving an order including one or more of a commitment of a buyer topurchase an item, and a preferred share value associated with the buyer.The preferred share value may represent at least a first portion of apurchase price associated with the item. The computer-readable storagemedium may also include one or more programming instructions forreceiving contact information associated with one or more third parties,receiving a fractional share value associated with each of the one ormore third parties, and in response to a sum of the fractional sharevalues associated with each third party and the preferred share valueequaling the purchase price associated with the item, using the receivedcontact information to send a message to each third party. Each messagemay include the fractional share associated with the third party.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a diagram of an exemplary environment for operationof a shared payment processing system according to an embodiment.

FIG. 2 illustrates a flow diagram of an exemplary illustrative methodfor processing single sale transactions involving one or more payorsaccording to an embodiment.

FIG. 3 illustrates a simplified example of data fields maintained in anexemplary data structure according to an embodiment.

FIG. 4 illustrates a block diagram of an exemplary shared paymentprocessing system according to an embodiment.

FIG. 5 illustrates an exemplary website interface according to anembodiment.

FIG. 6 illustrates an exemplary graphical user interface according to anembodiment.

FIG. 7 illustrates an exemplary order according to an embodiment.

FIG. 8 illustrates an exemplary confirmation according to an embodiment.

FIG. 9 illustrates an exemplary notification according to an embodiment.

DETAILED DESCRIPTION

A system and method for processing single sale transactions may involveone or more payors. More specifically, the system and method may involveobtaining a single buyer's commitment to purchase one or more itemsand/or services (collectively “items”) from a merchant at a purchaseprice (including any applicable, taxes, shipping, handling, surcharges,etc.). Thus, the merchant is assured that the sale transaction will becompleted, and any possible concern over timely availability of theitems as a gift, for a party, etc. is avoided.

Further, the system and method may facilitate recruitment of additionalpayors that may join in the purchase of the item by committing to fund ashare of the purchase price. The addition of any additional payorsreduces the financial obligation of the buyer. Further, payment may becollected from all payors substantially contemporaneously, thuseliminating any collection problems of a type sometimes encountered whenreimbursement is sought subsequent to a purchase sought, as discussedabove.

A shared payment processing system may be provided in the form of anInternet—or otherwise network-accessible website or service. Thus, theshared payment processing system may be configured to interface withe-commerce websites as well as computerized order management and/orpayment processing systems of traditional bricks-and-mortar typemerchant establishments. By way of example, the shared paymentprocessing system may maintain a website accessible via personalcomputers, PDAs, smartphones or other mobile computing devices usingconventional web browsing software, and/or a network-accessibleelectronic interface permitting EDI or other similar electronic exchangeof data with order management and/or payment processing systems ofmerchants.

As shown by FIG. 1, an exemplary networked environment 10 may include ashared payment processing system 200 that may be configured to carry outmethods described herein, as discussed in further detail with referenceto FIGS. 2-4. The shared payment processing system 200 may be configuredto present a website interface via which merchants, buyers and thirdparties may create respective user accounts, and/or otherwise providerelevant contact information, payment processing information, etc. tothe system 200.

The network environment 10 may include a conventional credit card orother payment (collectively, credit card) payment system, which is shownlogically for illustrative purposes only as a single-server credit cardpayment system 50. It will be appreciated that this system so representsexisting payment processing networks.

The network environment 10 may include a plurality of merchant systems20 a, 20 b, 20 c and a plurality of buyer systems 30 a, 30 b that maycommunicate with the shared payment processing system 200 via acommunications network 40, such as the Internet. Accordingly, each buyersystem 30 a, 30 b may include conventional computerized hardware andsoftware for receiving email and browsing the web, such as asuitably-configured personal computer, PDA, smart-phone, or the like.Each merchant system 20 a, 20 b, 20 c may include computerized hardwareand software for browsing the web, and for performing e-commerce relatedoperations, such as providing a web-based e-commerce “store” andinterfacing with the credit card payment processing system 50, asgenerally known in the art, or described herein.

FIG. 2 illustrates a flow diagram 100 of an exemplary method forprocessing single sale transactions involving one or more payorsaccording to an embodiment. By way of context, it may be considered thata buyer may browse a website-based e-commerce “store” of a web-basedretailer, such as Amazon, Inc. (amazon.com), Barnes & Noble, Inc.(bn.com), or eBay, Inc. (ebay.com) and may select one or more items forpurchase, e.g. using a conventional shopping cart or other interface.Accordingly, much of the shopping experience in the context of thepresent invention may occur using the buyer's personal computer (PC), aPDA, smart-phone or other mobile computing device, 30 a, 30 b as shownin FIG. 1.

The buyer may provide credit card or other payment information forexample via a website interface. In an embodiment, a checkbox or otheroption may be selected by the buyer to invoke the payment-sharingtechnology of the present invention. In another embodiment, themerchant's system may be configured such that simple providing of thecredit card or other payment information may automatically invoke thepayment-sharing technology of the present invention. In either case, byproviding the credit card/payment information and authorizing a chargein the full amount of the purchase price, the buyer has made anon-conditional commitment to purchase the selected item(s).

In accordance with the present invention, the buyer may be presented,via the website, with a confirmation, such as a confirmatory-email,message, text message and/or the like, with an option to treat thetransaction as a potential shared-payment transaction in accordance withthe present invention. FIG. 9 illustrates an exemplary confirmationaccording to an embodiment. If the buyer chooses to do so, then theshared payment processing system 200 and its operation may be invoked tocarry out the functionality described herein, as discussed in greaterdetail below with reference to FIG. 2.

FIG. 2 illustrates a flow diagram 100 of an exemplary illustrativemethod for processing single sale transactions involving one or morepayors according to an embodiment. Referring now to FIG. 2, thisexemplary method may begin with establishment of a merchant account foruse of the shared payment processing system 200 by a merchant, as shownin step 102. For example, this may involve an individual's operation ofa merchant system 20 a to log on to the shared payment processing system200 via a website interface presented by the shared payment processingsystem 200. Alternatively, this information may be gathered and providedto the system 200 without involvement of such a website interface. Amerchant account may be created, and associated information stored bythe shared payment processing system 200, in a conventional manner.Associated information may be stored as merchant account data 230 in amemory 218 of the system, e.g. in a database, as shown in FIG. 4.Establishment of the merchant account may involve providing one or moreof the merchant's name, address, payment processing information(accounts, communication parameters), etc. This may prepare the sharedpayment processing system 200 to interact with the merchant system 20 aon an as-needed basis.

As shown in FIG. 2, this exemplary method may involve establishment ofone or more buyer accounts for use of the shared payment processingsystem by buyers, as shown at step 104. For example, this may involve anindividual's operation of a buyer system 30 a, such as a personalcomputer (PC), a PDA, smart-phone or other mobile device, to log on tothe shared payment processing system via the website interface presentedby the shared payment processing system 200. FIG. 5 illustrates anexemplary website interface according to an embodiment. A buyer accountmay be created, and associated information stored by the shared paymentprocessing system 200, in a conventional manner. Associated informationmay be stored as buyer account data 232 in a memory 218 of the system,e.g. in a database, as shown in FIG. 4. Establishment of the buyeraccount may involve providing a record of the buyer's name, mailingaddress, e-mail address, and payment processing (e.g. credit card)information. This may prepare the shared payment processing system 200to interact with the buyer system 30 a on an as-needed basis.

The shared payment processing system 200 may receive a buyer'snon-conditional commitment to purchase from the merchant a specific item(or items) at a specific purchase price, as shown at step 106. Forexample, this commitment may be in the form of an indication,transmitted from the buyer device or the merchant device to the sharedpayment system 200 indicating that the buyer has provided credit card orother payment information and authorized a payment in the amount of, orcommitted to accepting a charge up to the full amount of the purchaseprice. In an embodiment, this information may be transmitted to theshared payment system after the buyer operates a web-browsing or otheruser interface to follow a link in a confirmatory-email sent to thebuyer by the merchant, etc. to a website interface presented by theshared payment processing system and permitting the buyer to initiate ashared-payment transaction.

Optionally, information relating to the purchase transaction may betransmitted from the merchant system, e.g. 20 a, to the shared paymentprocessing system 200 in connection with the shared payment processingsystem's receipt of the buyer's non-conditional commitment to purchasefrom the merchant an item (or items) at a purchase price. Theinformation transmitted from the merchant system, e.g. 20 a, to theshared payment processing system 200 may include, for example, one ormore of the vendor's website address and/or other contact information,information identifying the item, the purchase price, and the buyer'spayment processing information, such as a credit card number. Thisnon-conditional commitment may be expressed in any suitable one ofvarious ways, as will be appreciated by those skilled in the art. Forexample, in one embodiment, all information typically gathered by themerchant, e.g. via the merchant's website, may be gathered by themerchant, and then one or more of merchant identification information,buyer identification information, item identification information, priceidentification information and payment identification information may betransmitted from the merchant system 20 a to the shared paymentprocessing system 200, and the receipt of such information is taken bythe shared payment processing system 200 to be the buyer'snon-conditional commitment. Alternatively, for example, all suchinformation may be gathered from the buyer by the shared paymentprocessing system 200, or from both the merchant system 20 a and thebuyer by the shared payment processing system 200. By way of furtherexample, the shared payment processing system 200 may receive only asubset of such information, such as merchant identification informationand price identification information, and the receipt of suchinformation may be taken by the shared payment processing system 200 tobe the buyer's non-conditional commitment. Alternatively, a differentsignal may be used to signal the buyer's non-conditional commitment, andany required information may subsequently be gathered by the sharedpayment processing system 200.

The buyer's commitment, in the context of a shared-payment transaction,may be to complete the transaction within a defined period of time, asshown in step 106, regardless of whether any additional payors will makecontributions toward the purchase price. The defined period of time maybe preferably explicitly presented to the buyer by the system 200, oracknowledged by the buyer in some other manner. In one embodiment, theshared payment system 200 may be configured to use a predeterminedperiod of time for all buyers, or classes of buyers or classes ofpurchases. For example, the system may be configured to store suchperiod information in its memory 218, e.g. a period measuring one monthfrom the buyer's commitment to purchase the item(s). In anotherembodiment, the system 200 is configured to present each buyer with agraphical user interface, e.g. via its website interface, that permitsthe buyer to establish a period of time to be used for that buyer'stransaction. For example, a buyer could specify that the purchase becompleted on a date that is a period of 2 weeks from the commitmentdate. Alternatively, the buyer could specify a particular date on whichthe determination is to be made, e.g., Aug. 3, 2008, to allow for timeto ship and wrap the item(s) in advance of a birthday or other party ona predetermined date on which the buyer will want to be in possession ofthe item(s). In other embodiments, the merchant may specify the timeperiod to be used, for all its buyers, for certain classes of buyers,for certain classes of items, etc.

The separation in time between the buyer's commitment date and the dateof completion of the transaction provides time for additional payors tojoin in a group contributing toward purchase of the item(s). However,the certainty of a date on which the transaction will take place,regardless of whether any additional payors are successfully recruited,ensures that the transaction will take place, and eliminates uncertaintyfor the merchants.

The shared payment processing system 200 may receive from the buyer anindication of the buyer's preferred share, as shown at step 108. Thebuyer's preferred share is a reflection of the amount of the totalpurchase price that the buyer would prefer to pay. Accordingly, althoughthe buyer has committed to paying the full purchase price for the item,the buyer may nevertheless seek to pay for only a fractional share ofthe purchase price, e.g., provided that third parties join in thetransaction to make a group purchase of the item, with a fractionalshare of the purchase being borne by each of the buyer and eachparticipating third party. For example, a buyer may commit to purchasingan anniversary gift for his parents (in the amount of $300), but mayseek to pay a preferred share of $100, provided that each of his twosiblings join in the transaction and commit to funding a fractionalshare of $100 each.

The shared payment processing system 200 then receives from the buyercontact information for communicating with one or more third parties, asshown at step 110. As used herein, a “third party” is an entity capableof funding a payment that is neither the buyer nor the merchant. Forexample, the buyer may provide to the shared payment processing system200 via its website interface, e-mail addresses of one or more thirdparties. Alternatively, the contact information may be in the form ofthe buyer's selection of a predefined group (e.g. XYZ community church,ABC University Alumni Association, etc.) for which the system retrievesrelevant email addresses or other contact information. In an embodiment,the contact information may be in the form of information associatedwith a third party on a social networking website, tool, program and/orthe like. In an embodiment, the contact information may include atelephone number, such as a number associated with a cellular telephone,a landline, mobile devices and/or the like. This information may beprovided by the buyer via the system's website interface. The systemstores contact information from the instructions in its memory 218 asthird party contact data 234, as shown in FIG. 4. For illustrativepurposes, FIG. 3 shows an exemplary simplified data structure showing,for example, five third-party e-mail addresses provided by a buyer(Buyer 1 ID) and stored as transaction data in association with aparticular transaction record (record #1 in this example) involving thebuyer (Buyer 1 ID).

The system 200 may present the buyer with a graphical user interface,e.g. via the system's website, permitting the buyer to identify aspecific fractional share proposed by the buyer to be paid by each ofthe third parties, and the system 200 then receives from the buyer anindication of a specific fractional share to be paid by a first (ornext) third party, as shown at step 112. As used herein, a “fractionalshare” is any portion that is greater than 0% and less than 100% of theentire purchase price. It will be appreciated that any one of variousdifferent methods may be used for defining the fractional shares. By wayof example, the shares may be predetermined by the system 200 or may bespecified by the buyer. The shares may be identical, or different. Theshares may be expressed in percentages, or in dollars or other units ofcurrency, such as dollars. Alternatively the shares may be expressed interms of a minimum dollar or percentage amount, and funding commitmentsexceeding the minimum will be accepted. FIG. 6 illustrates an exemplarygraphical user interface that may permit a buyer to provide a preferenceshare value, third-party information, fractional share value(s) and/orthe like.

As shown at step 114 of FIG. 2, the shared payment processing system 200may check to determine whether the sum of the buyer's preferred shareand all the fractional shares assigned by the buyer to third partiesequals the total amount of the purchase price for the item(s). If not,then the system 200 may continue to prompt the buyer and receive fromthe buyer indications of fractional shares to be paid by third parties,as shown at steps 114 and 112. This may continue until fractional shares(including the buyer's preferred share) totaling the purchase price havebeen assigned among the buyer and third parties.

If the system determines in step 114 that the sum of the buyer'spreferred share and all the fractional shares assigned to third partiesequals the total amount of the purchase price for the item(s), then thesystem may 200 “lock” the order, as shown at step 116. Locking of theorder confirms that the assignment of fractional shares is complete, andcauses the defined period of time for completing the order to begin torun. FIG. 7 illustrates an exemplary locked order according to anembodiment.

After the order has been locked, the shared payment processing system200 may transmit invitations to the third parties using the contactinformation provided by the buyer, as shown at step 118. The invitationsinvite third parties to join a purchase group for the item(s) that thebuyer has committed to purchase from the merchant. The buyers areinvited to join the purchase group by committing to fund a fractionalshare of the purchase price.

Each invitation may include an identification of the item/items, themerchant from which it/they are to be purchased, and a textualsolicitation to join in the purchase group by funding a fractional shareof the purchase price, etc. The invitation may be provided in the formof an email message transmitted from the shared payment processingsystem 200 (or merchant system) to the individual e-mail addressesprovided by the buyer. In an embodiment, the invitation may be sent to athird party using contact information associated with a socialnetworking website, tools, program and/or the like. In an embodiment,the invitation may be provided in the form of a text message, such as ashort messaging service (“SMS”) message, a multimedia messaging service(“MMS”) message and/or the like.

In a preferred embodiment, each invitation identifies a specificfractional share to be paid by a respective third party, and seeks thethird party's commitment to fund the fractional share. The fractionalshare to be paid by each third party may be specified by the buyer, inview of the buyer's identification of a specific fractional shareintended to be paid by the buyer (the buyer's preferred share). Incertain embodiments, the system may be configured such that each thirdparty may only agree to or refuse to fund the specified fractionalshare. In other embodiments, the system may be configured to permit eachthird party may choose to fund a fractional share in the exact amount ofthe specified fractional share, in an amount greater than the specifiedfractional share, or in an amount less than the specified fractionalshare. In alternative embodiments, the system may be configured toprovide an indication that the proposed fractional shares are defined inamount, but not assigned to any specific third parties, and that afunding commitment from any third party in any amount should beaccepted.

In a preferred embodiment, the invitation may be transmittedelectronically from system 200 as an email message. The invitation mayinclude any suitable content. For example, the invitation may includeinformation about the goods, e.g. of a type typically included in ane-commerce website selling the good (including information extractedfrom the merchant's website), a hyperlink to the merchant's website,etc.

By way of example, each third party may browse an email invitation usinga conventional email client device, such as a conventional personalcomputer, smart-phone, etc. configured with appropriate conventionalemail client software. Any third party choosing to make a commitment tofund a fractional share may do so in a straightforward manner, e.g. byselecting a link contained in the email and interacting with anappropriate website interface to select a particular fractional share,and to provide payment processing information, such as credit cardinformation. By doing so, the third party may effectively authorize acharge in a specific amount to a specific charge/payment account. Asdiscussed above, in certain embodiments, the system may be configuredsuch that each third party may only agree to or refuse to fund thespecific fractional share specified by the buyer (e.g., $500). In otherembodiments, the system may be configured to permit each third party tochoose to fund a fractional share in the exact amount of the specifiedfractional share (e.g., $500), in an amount greater than the specifiedfractional share (e.g., $600), or in an amount less than the specifiedfractional share (e.g., $400). In response to the third parties' actionsto fund a fractional share, the system 200 may receive the thirdparties' funding commitments, as shown at step 120. For example, thismay include receiving information identifying the third party, theamount of the fractional share to be funded, and the third party paymentprocessing information. That information may be stored by the sharedpayment processing system 200 as third party payor data 236 in thememory 218 of the system 200, as shown in FIG. 4. FIG. 8 illustrates anexemplary interface showing a funding commitment and informationconcerning processing of payment information according to an embodiment.

Exemplary share commitments and payment processing information is shownin the exemplary data structure of FIG. 3 for illustrative purposes. Inthe example illustrated in record 1 of FIG. 3, the buyer having a userID of Buyer 1 ID defined fractional shares for the third parties of$200, $100, $100, $50 and $50, and further defined the buyer's preferredshare as $250. For example, FIG. 3 shows that the third party having theemail address TP1@email1.com made a $200 funding commitment, and thethird party having the email address TP2@email2.com made a $100 fundingcommitment, etc. Thus, these third parties made funding commitments inthe exact amount of fractional shares proposed by the buyer.

By way of further example, record 2 shows that a buyer having a user IDof Buyer 2 ID chose to define equal (identical) fractional shares of$100 each. However, in this embodiment, the third party having the emailaddress TP8@email8.com made a funding commitment ($200) in an amountgreater than the buyer's proposed fractional share ($100), and the thirdparty having the email address TP9@email9.com made a funding commitment($50) in an amount less than the buyer's proposed fractional share($100). The shared payment processing system 200 may determines whetherit has received funding commitments equal to the share price, as shownat step 122. For each third party, the respective funding commitmentsare those funding commitments provided by the third parties in aspecific amount. For the buyer, the buyer's funding commitment at thisstage is taken to be the buyer's preferred share. If so, then the sharedpayment processing system 200 may initiate processing of payments fromeach third party having joined the purchase group, e.g. having made ashare funding commitment, according to their respective fundingcommitments, as shown at step 128 and as discussed further below.

If, however, it is determined in step 122 that funding commitments havenot been received for all fractional shares, i.e. that the sum of thefractional shares for which funding commitments have been made by thirdparties plus the buyer's preferred share is less than the purchaseprice, then the shared payment processing system 200 next determineswhether the predetermined period of time has expired, as shown at step124. If the time period has not yet expired, then the “contributionperiod” is still open, and the system may wait to determine whetheradditional fractional share commitments will be received from thirdparties, as shown at steps 126 and 120. An illustrative example of thiscase is shown as record 3 in FIG. 3.

If commitments have not been received for all fractional shares but itis determined in step 124 that the period of time has expired, then the“contribution period” has closed, and the transaction may be completed.Accordingly, the shared payment processing system 200 may proceed toinitiate processing of payments from each third party having joined thepurchase group in the amounts of their respective fractional shares, asshown at step 128.

With respect to the payment processing of step 128, the shared paymentprocessing system 200 may initiate the payment processing in anysuitable manner, as discussed above. In this example, the shared paymentprocessing system 200 may communicate directly with the credit cardpayment system 50. Accordingly, in the example of record 1 of FIG. 3,the shared payment processing system 200 may proceed to initiate acharge of $200 to credit card account number 1234 567890 12345 (payableby Third Party 1), a next charge of $100 to credit card account number9876 5432 1098 7654 (payable by Third Party 2), etc. by transmittingrelevant charge amount and charge account information to the credit cardpayment system 50. Any amount successfully charged to a third party maybe stored as actual contribution data 238 in the memory of the sharedpayment processing system 200. Any failed charge, e.g. due to exceedingof a credit limit, expiration of a charge account, etc., results in afailure to record the amount of the attempted charge as an actualcontribution toward the purchase of the item(s).

Each third party's actual contribution may be equal to its fundingcommitment. The buyer's actual contribution, however, may be determinedby subtracting the funding commitments of the third parties from thepurchase price, which was the buyer's original commitment. In certaincircumstances, the third party's actual contribution might be taken tobe $0 if, for example, a charge to that third party's credit card in theamount of that third party's funding commitment is denied, etc. In thisevent, the buyer's actual contribution may increase by the amount ofthat third party's failed funding commitment.

In a certain embodiment, the shared payment processing system 200, afterdetermining the amounts to be charged to the buyer and each committedthird party, may communicate directly with the credit card paymentsystem 50, e.g. via communications network 40, to effect the payments,and then report completion of the payment transactions to the merchant'ssystem 30 a, etc., e.g. via communication network 40, to signal themerchant to proceed to a fulfillment process for the order, by which aprocess is set in motion to ship the purchased good to the buyer, etc.In another embodiment, the shared payment processing system 200, afterdetermining the amounts to be charged to the buyer and each committedthird party, may communicate each charge amount, charge account, andrelated information to the merchant system 30 a, e.g. via communicationsnetwork 40, and the merchant system 30 a communicates directly with thecredit card payment system 50, e.g. via communications network 40 toeffect the payments, and then proceeds to the fulfillment process. Inthis example, the system 200 may determine the balance due by the buyerin view of the actual third parties' contributions (resulting fromsuccessful payment processing transactions), as shown at step 130. Forexample, if the third parties have made actual contributions totaling$500 ($200+$100+$100+$50+$50), and the purchase price is $750, then thebuyer's balance due is $250 ($750-$500), as shown in the example ofrecord 1 in FIG. 3. The buyer's balance due may be calculated and storedas contribution data 238 in the memory 218 of the system. See FIG. 3. Itwill be noted that in the example of record 2 of FIG. 3, the balance dueby the buyer is not equal to the buyer's preferred share because ofdifferences between the fractional share amounts specified by the buyerfor third parties and the amounts of funding commitments of those thirdparties.

The system then initiates processing of the buyer's payment in theamount of the balance due, as shown at step 132, and the method ends asshown at step 134.

FIG. 4 is a block diagram of a shared payment processing system (shownlogically as a single representative server for ease of illustration)200 (see FIG. 1) according to an embodiment. The shared paymentprocessing system 200 may include server hardware storing executingspecially-configured computer software for carrying out a method inaccordance with the present invention. Accordingly, the shared paymentprocessing system 200 of FIG. 4 may include a microprocessor (CPU) 202and a bus 204 employed to connect and enable communication between themicroprocessor 202 and the components of the shared payment processingsystem 18 in accordance with known techniques. The shared paymentprocessing system 18 may include a user interface adapter 206, whichconnects the microprocessor 202 via the bus 204 to one or more interfacedevices, such as a keyboard 208, mouse 210, and/or other interfacedevices 212, which can be any user interface device, such as a touchsensitive screen, digitized entry pad, etc. The bus 204 also connects adisplay device 214, such as an LCD screen or monitor, to themicroprocessor 202 via a display adapter 216. The bus 204 also connectsthe microprocessor 202 to memory 218, which can include a hard drive,diskette drive, tape drive, etc.

The shared payment processing system 200 may communicate with othercomputers or networks of computers, for example via a communicationschannel, network card or modem 222. The shared payment processing system200 may be associated with such other computers in a local area network(LAN) or a wide area network (WAN), and operates as a server in aclient/server, arrangement with another computer, etc. Suchconfigurations, as well as the appropriate communications hardware andsoftware, are known in the art.

The shared payment processing system's software may be speciallyconfigured in accordance with the present invention. Accordingly, asshown in FIG. 4, the shared payment processing system 200 may includecomputer-readable, microprocessor-executable instructions stored in thememory for carrying out the methods described herein. Further, thememory stores certain data, e.g. in databases or other data stores shownlogically in FIG. 4 for illustrative purposes, without regard to anyparticular embodiment in one or more hardware or software components.For example, FIG. 4 shows schematically storage in the memory 218 ofmerchant account data 230, buyer account data 232, and transaction dataincluding third party contact data 234, third party payor data(including credit card or other charge account information) 236 andcontribution data 238.

Additionally, computer readable media storing computer readable code forcarrying out the method steps identified above may be provided. Thecomputer readable media may store code for carrying out subprocesses forcarrying out the methods described above.

A computer program product recorded on a computer readable medium forcarrying out the method steps identified above may be provided. Thecomputer program product may include computer readable instructions forcarrying out the methods described above.

While there have been described herein the principles of the invention,it is to be understood by those skilled in the art that this descriptionis made only by way of example and not as a limitation to the scope ofthe invention.

It will be appreciated that various of the above-disclosed and otherfeatures and functions, or alternatives thereof, may be desirablycombined into many other different systems or applications. Also thatvarious presently unforeseen or unanticipated alternatives,modifications, variations or improvements therein may be subsequentlymade by those skilled in the art which are also intended to beencompassed by the following claims.

What is claimed is:
 1. A system for processing sales transactions, thesystem comprising: a first computing device in communication with abuyer-operated computing device; a computer-readable storage medium incommunication with the first computing device, wherein thecomputer-readable storage medium comprises one or more programminginstructions for: receiving an order comprising one or more of: acommitment of a buyer to purchase an item, and a preferred share valueassociated with the buyer, wherein the preferred share value representsat least a first portion of a purchase price associated with the item,receiving contact information associated with one or more third parties,receiving a fractional share value associated with each of the one ormore third parties, and in response to a sum of the fractional sharevalues associated with each third party and the preferred share valueequaling the purchase price associated with the item, using the receivedcontact information to send a message to each third party, wherein eachmessage comprises the fractional share associated with the third party.2. The system of claim 1, wherein the computer-readable storage mediumcomprises one or more programming instructions for receiving a responsefrom at least one of the one or more third parties, wherein the responsecomprises a funding commitment value equal to a portion of the purchaseprice to be paid by the third party.
 3. The system of claim 2, whereinthe computer-readable storage medium comprises one or more programminginstructions for processing payment of the funding commitment valuesfrom the third parties.
 4. The system of claim 3, wherein theprogramming instructions for processing payment of The fundingcommitment values comprise one or more programming instructions for oneor more of the third parties, transmitting the funding commitment valueand charge account information associated with the third party to acredit card payment system.
 5. The system of claim 4, wherein thecomputer-readable storage medium further comprises one or moreprogramming instructions for receiving, from the credit card paymentsystem, an indication of a failed charge associated with one or more ofthe third parties; and determining a balance owed by the buyer by:determining a first value equal to a difference between the purchaseprice and a sum of the funding commitment values associated with thethird parties, determining the funding commitment value associated withthe third party having the failed charge, and summing the first valueand the determined funding commitment value.
 6. The system of claim 3,wherein the computer-readable storage medium comprises one or moreprogramming instructions for determining a balance owed by the buyer bydetermining a difference between the purchase price and a sum of thefunding commitment values associated with the third parties; andprocessing payment of the balance from the buyer.
 7. The system of claim6, wherein the programming instructions for processing payment of thebalance comprise one or more programming instructions for transmittingthe balance and charge account information associated with the buyer toa credit card payment system.
 8. The system of claim 2, wherein thecomputer-readable storage medium comprises one or more programminginstructions for in response to a sum of the funding commitment valuesreceived from the third parties and the preferred share value equalingthe purchase price, processing payment of the funding commitment valuesfrom the third parties.
 9. The system of claim 8, wherein theprogramming instructions for processing payment of the fundingcommitment values comprise one or more programming instructions for oneor more of the third parties, transmitting the funding commitment valueand charge account information associated with the third party to acredit card payment system.
 10. The system of claim 8, wherein thecomputer-readable storage medium comprises one or more programminginstructions for determining a balance owed by the buyer by determininga difference between the purchase price and a sum of the fundingcommitment values associated with the third parties; and processingpayment of the balance from the buyer.
 11. The system of claim 1,wherein the computer-readable storage medium comprises one or moreprogramming instructions for: determining whether funding commitmentvalues have been received from one or more of the third parties;determining a balance owed by the buyer by determining a differencebetween the purchase price and a sum of the received funding commitmentvalues; processing payment of the funding commitment values from thethird parties; and processing payment of the balance from the buyer. 12.The system of claim 1, wherein the one or more programming instructionsfor receiving a commitment of a buyer comprises one or more programminginstructions for receiving one or more of the following: merchantidentification information; buyer identification information; itemidentification information; price identification information; andpayment identification information.
 13. The system of claim 1, whereinthe one or more programming instructions for receiving contactinformation associated with one or more third parties comprise one ormore programming instructions for receiving one or more email addressesassociated with each of the third parties.
 14. The system of claim 1,wherein the one or more programming instructions for receiving afractional share value associated with each of the one or more thirdparties comprise one or more programming instructions for receiving adifferent fractional share value for each of the third parties.
 15. Thesystem of claim 1, wherein the one or more programming instructions forreceiving a fractional share value associated with each of the one ormore third parties comprise one or more programming instructions forreceiving a same fractional share value for each of the third parties.16. The system of claim 1, wherein the one or more programminginstructions for receiving a fractional share value associated with eachof the one or more third parties comprise one or more programminginstructions for in response to the sum of the fractional share valuesassociated with each of the third parties and the preferred share valuenot equaling the purchase price, prompting the buyer to providefractional share values for the third parties.
 17. The system of claim1, wherein the one or more programming instructions for using thereceived contact information to send a message to each third partycomprise one or more programming instructions for sending an emailmessage to each third party comprising one or more of the following: anidentification of the item; a merchant from which the item is to bepurchased; and a textual solicitation to fund the fractional sharevalue.